The present invention relates to communicating information in a distributed objects system, and more particularly relates to a publish and subscribe event communications object model and services for delivering and filtering events between loosely coupled objects.
A prevalent programming problem is that of advertising availability of and distributing information to interested parties without a priori knowledge of their identity. In these situations, there are two types of programs involved: a program that produces information and one or more programs that consume the information. For efficiency, it is preferable that the information producer proactively notify the interested information consumers when information becomes available, rather than force the consumer to repeatedly call or poll for available information. Yet, the identity of the consumers is not known a priori by the producer (e.g., at development or compile time of the producer program). This programming problem is encountered in a variety of situations from delivering information between very granular objects running in a single process to delivering information across an enterprise between very large applications. For example, it may be desirable to inform several thousand employees of an enterprise when its stock price reaches a given amount, or inform managers when certain tasks in a project are complete, among many other information distribution scenarios. Also, a number of network or enterprise events are of interest to many applications, such as changes in network security policy, replication failures, network printer failure, or moving server software to a new machine. There also are a large number of events that occur within a single machine and have great utility, including login/logout, network connect/disconnect, startup/shutdown, disk full, CPU idle, etc.
Traditional object-oriented programming models and systems use method calls according to a request/reply model to communicate data between objects. Object-oriented programming models, such as the Microsoft Component Object Model (xe2x80x9cCOMxe2x80x9d), define a standard structure of software objects that can be interconnected and collectively assembled into an application (which, being assembled from component objects, is herein referred to as a xe2x80x9ccomponent applicationxe2x80x9d). The objects are hosted in an execution environment created by system services, such as the object execution environments provided by COM. This system exposes services for use by component application objects in the form of application programming interfaces (xe2x80x9cAPIsxe2x80x9d), system-provided objects and system-defined object interfaces.
In accordance with object-oriented programming principles, the component application is a collection of object classes which each model real world or abstract items by combining data to represent the item""s properties with functions to represent the item""s functionality. More specifically, an object is an instance of a programmer-defined type referred to as a class, which exhibits the characteristics of data encapsulation, polymorphism and inheritance. Data encapsulation refers to the combining of data (also referred to as properties of an object) with methods that operate on the data (also referred to as member functions of an object) into a unitary software component (i.e., the object), such that the object hides its internal composition, structure and operation and exposes its functionality to client programs that utilize the object only through one or more interfaces. An interface of the object is a group of semantically related member functions of the object. In other words, the client programs do not access the object""s data directly, but must instead call functions on the object""s interfaces to operate on the data.
Polymorphism refers to the ability to view (i.e., interact with) two similar objects through a common interface, thereby eliminating the need to differentiate between two objects. Inheritance refers to the derivation of different classes of objects from a base class, where the derived classes inherit the properties and characteristics of the base class.
These object-oriented programming models traditionally use a request/reply model to communicate data between objects. In the request/reply model, one object (typically the object that consumes or acts on the information) implements an incoming interface. FIG. 1, for example, shows a program listing 10 according to COM of an xe2x80x9cIStockEventsxe2x80x9d interface exposed by an object to receive communications of stock information, such as stock symbols and price updates. A client of the object (such as one that produces information acted on by the object) communicates with the object through the incoming interface, by first creating the object and calling a method in the interface of the object. FIG. 2, for example, shows a program listing 12 of client code to communicate stock information to the object by calling a method in the IStockEvents interface. In such request/reply models, however, there is a one-to-one relationship between the client and object. Also, the identity of the object must be xe2x80x9cknownxe2x80x9d a priori to the client. Specifically, the relationship of client to object is xe2x80x9cearly-bound,xe2x80x9d i.e., established at development by compiling in a class identifier (e.g., shown in FIG. 2 by the xe2x80x9cCLSID_StockSubscriberxe2x80x9d parameter of the xe2x80x9cCoCreateInstance( )xe2x80x9d call).
A more effective approach to this distribution problem (i.e., of many unknown consumers) is to use a publish and subscribe event communications model, which generally provides an information distribution mechanism that in many ways resembles the magazine publishing industry. In magazine publishing, a publisher (e.g., McGraw-Hill) advertises magazines (e.g., Byte magazine) to potential subscribers. Subscriptions to a given magazine are placed by the subscriber or possibly also by another person on behalf of the subscriber. The subscription is an agreement by the publisher to distribute an event (e.g., issues of the magazine) to the subscriber when the event is produced by the publisher. Publish and subscribe event communications models use a similar approach for distributing information from a producing program (the xe2x80x9cpublisherxe2x80x9d) to a consuming program (the xe2x80x9csubscriberxe2x80x9d).
Two representative publish and subscribe event communications models are Sun Microsystems"" JavaBeans(trademark) Events architecture and the Connection Points model of Microsoft Corporation""s Component Object Model (hereafter, COM Connection Points). Both of these feature an internal events model in which the eventing semantic is completely contained within the scope of the publisher and subscriber. In other words, the subscriber contains the program code that implements the subscription logic.
More specifically, JavaBeans(trademark) Events defines structures of a set of interfaces to be implemented by the publisher and subscriber, as well as an event object with standard interfaces. The publisher (called an xe2x80x9cevent sourcexe2x80x9d) identifies itself as sourcing particular events by implementing registration methods that conform to a specific design pattern (e.g., declared as xe2x80x9cFooListener AddFooListener(FooListener fel);xe2x80x9d in the Java programming language) and accept references to instances of particular subscriber""s (called an xe2x80x9cevent listenerxe2x80x9d) interfaces. The information produced by the event source is encapsulated in an xe2x80x9cevent statexe2x80x9d object (which is derived as a subclass from xe2x80x9cjava.util.EventObjectxe2x80x9d). The subscriber identifies itself as interested in particular events by implementing some set of xe2x80x9cevent listenerxe2x80x9d interfaces with methods that receive the event state object. The subscriber must include code to call the registration method of the publisher and pass a reference to its event listener interface. The publisher, on the other hand, contains code that, upon producing information which is to be published, creates an event state object to contain the information and calls an appropriate method on the registered event listener interfaces of the event listener to which the event state object is passed.
In COM Connection Points, a publisher (called a xe2x80x9cconnectable objectxe2x80x9d) defines outgoing interfaces and provides an associated xe2x80x9cconnection pointxe2x80x9d sub-object for distributing information to interested xe2x80x9cclient objectsxe2x80x9d or subscribers. The connectable object implements an interface, xe2x80x9cIConnectionPointContainer,xe2x80x9d which indicates the existence of outgoing interfaces. The client object uses the xe2x80x9cIConnectionPointContainerxe2x80x9d interface to obtain a reference to an interface, xe2x80x9cIConnectionPoint,xe2x80x9d of the connection point sub-object for a desired outgoing interface (specified by an interface identifier or xe2x80x9cIIDxe2x80x9d) defined by the connectable object. Using the xe2x80x9cIConnectionPointxe2x80x9d interface, the client object establishes an advisory connection with the connectable object by passing in a reference to a sink object that implements the desired outgoing interface. The connectable object then publishes an event via calls to the connected outgoing interfaces.
In both the JavaBeans(trademark) Events and COM Connection Points models, the subscriber is required to contain xe2x80x9csubscription logicxe2x80x9d (i.e., program code) that establishes the subscription or connection from the publisher to the subscriber. In JavaBeans(trademark) Events, the event listener contains logic to locate the appropriate event source that produces event state objects with desired information, and to register its event listener interface with that event source so as to receive the event state object. In COM Connection Points, the client object contains logic to locate the appropriate connectable object that produces desired information, and establish an advisory connection with the connectable object to the client object""s sink interface. This need in such internal event models to incorporate subscription logic built into the publisher and/or subscriber complicates the programming model, making it more difficult for developers to write application objects that make use of the event model for information distribution.
A further disadvantage of these event communications models is that the publisher and subscriber are required to have concurrent lifetimes. In JavaBeans(trademark) Events, the event listener registers an xe2x80x9cevent listenerxe2x80x9d interface reference with the event source. In COM Connection Points, the client object passes a sink object interface reference to the connection point object to establish the advisory connection from the connectable object. In either case, the interface reference is only valid during the lifetime of the event listener or client sink object, requiring that the subscriber and publisher be in existence (i.e., instantiated) when the subscription is made and when the event is published.
The JavaBeans(trademark) Events model also specifies that the subscriber can, in place of registering its own xe2x80x9cevent listenerxe2x80x9d interface, instead register the interface of an intermediary referred to as an xe2x80x9cevent adaptorxe2x80x9d with the publisher. The event adaptor interposes between the publisher and subscriber to provide some additional xe2x80x9cpolicyxe2x80x9d on event delivery, such as to act as a filter of which of the events published by the publisher are delivered to the subscriber. This arrangement suffers many of the above noted disadvantages in that the subscriber must implement subscription logic that also creates and registers the event adaptor with the publisher, and also the event adaptor along with the subscriber and publisher are required to have concurrent lifetimes. Further, only the subscriber has the capability to place additional policy via registering the event adaptor.
The present invention provides a publish and subscribe event communications model which, among other features, supports filtering of published events. The model supports filtering at the publisher and/or subscriber-side of the model. The model further allows filtering logic and criteria to be specified externally of the publisher and subscriber, and independently of the publisher and subscriber lifetimes.
More specifically, in an embodiment of the invention illustrated herein, an event system stores subscriptions that represent a relationship of an outgoing interface method (that is called by the publisher to fire an event) to a subscriber. The subscription also can contain a set of publisher and subscriber properties, which in the illustrated embodiment are name/value pairs that are used as the basis for filtering events. For example, the name can be a parameter of the outgoing interface method, and the value can be used by filtering logic to determine whether a particular method call of the publisher to the outgoing interface method should result in delivering the event to the subscriber.
Further, for publisher-side filtering, the publisher installs a publisher filter into the event distribution code of the event system at run-time. The publisher filter can contain filtering logic that uses the publisher and subscriber properties in the subscription to determine whether a particular event of the publisher is delivered to the subscriber. The publisher, in effect, can install a publisher filter to provide any desired custom processing at event delivery that need not be related to the subscription-stored properties. For example, the publisher filter can implement logic to sort or order delivery of the publisher""s event to its subscribers.
For subscriber-side filtering, the subscription specifies a subscriber filter in place of the ultimate subscriber to the publisher""s events. Such subscriptions can be placed with the event system by subscription logic in the subscriber itself. Alternatively, the subscription having a subscriber filter can be placed externally of the subscriber, such as by an administrator using an administration utility or by other programs. The subscription can specify the subscriber filter using a class identifier or like program identifier with which an instance of the subscriber filter can be created, rather than an interface pointer or other link to a running program instance. This allows the subscriber filter""s lifetime to be independent of the publisher and subscriber""s lifetimes. The subscriber filter also need not exist at the time the subscription is placed with the event system.
In addition to supporting the outgoing interface, the subscriber filter supports a system-defined xe2x80x9csubscriber controlxe2x80x9d interface. Prior to delivering an event, the event system calls the subscriber filter on the subscriber control interface to allow the subscriber filter to perform processing based on the properties contained in the subscription.
Additional features and advantages of the invention will be made apparent from the following detailed description of an illustrated embodiment which proceeds with reference to the accompanying drawings.